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(57) Abstract: A novel method and apparatus is disclosed for performing seamless handoff of a mobile station (MS) between Ra- 
dio Access Networks (RANs) that use different types of wireless interfaces. The described embodiments enable an MS to handoff 
between different RANs without causing routing ambiguity, and without substantial loss of network data. Upon moving from the 
coverage area of a first RAN using a first wireless interface to the coverage area of a second RAN using a second wireless inter- 
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a re-registration of its network address. A foreign agent (FA) within a packet data serving node (PDSN) monitors network address 
re -registrations are being created for the same MS. Based on this determination, the PDSN terminates redundant R-P network con- 
nections resulting from movement of the MS between different RANs. 
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METHOD AND APPARATUS FOR HANDOFF OF A WIRELESS 
PACKET DATA SERVICES CONNECTION 

BACKGROUND 

5 

I. Field 

The present invention relates to wireless communications. More 
particularly, the present invention relates to a novel method and apparatus for 
performing seamless handoff of a mobile station between radio access networks 
10 having different wireless interfaces during wireless packet data service 
operation. 

II. Background 

15 The use of code division multiple access (CDMA) modulation techniques 

is one of several techniques for facilitating communications in which a large 
number of system users are present. Other multiple access communication 
system techniques, such as time division multiple access (TDMA), frequency 
division multiple access (FDMA) and AM modulation schemes such as 

20 amplitude companded single sideband (ACSSB) are known in the art. These 
techniques have been standardized to facilitate interoperation between 
equipment manufactured by different companies. Code division multiple 
access communication systems have been standardized in the United States in 
Telecommunications Industry Association TIA/EIA/IS-95-B, entitled "MOBILE 

25 STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE 
WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEMS", and referred to 
herein as IS-95. In addition, a new standard for CDMA communication systems 
has been proposed in the United States in Telecommunications Industry 
Association (TIA), entitled "Upper Layer (Layer 3) Signaling Standard for 

30 cdma2000 Spread Spectrum Systems, Release A — Addendum 1", dated 
October 27, 2000, and referred to herein as "lx." An additional standard for 
providing high speed data services has been proposed in the TIA, entitled 
"cdma2000 High Rate Packet Data Air Interface Specification," dated October 
27, 2000, and referred to herein as "LTDR." 

35 The International Telecommunications Union recently requested the 

submission of proposed methods for providing high rate data and high-quality 
speech services over wireless communication channels. A first of these 
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proposals was issued by the Telecommunications Industry Association, entitled 
"The IS-2000 ITU-R RTT Candidate Submission." A second of these proposals 
was issued by the European Telecommunications Standards Institute (ETSI), 
entitled "The ETSI UMTS Terrestrial Radio Access (UTRA) ITU-R RTT 
5 Candidate Submission", also known as "wideband CDMA" and hereinafter 
referred to as "W-CDMA." A third proposal was submitted by U.S. TG 8/1 
entitled "The UWC-136 Candidate Submission", hereinafter referred to as 
"EDGE." The contents of these submissions is public record and is well known 
in the art. 

10 IS-95 was originally optimized for transmission of variable-rate voice 

frames. Subsequent standards have built on the standard to support a variety 
of additional non-voice services including packet data services. One such set of 
packet data services was standardized in the United States in 
Telecommunications Industry Association TIA/EIA/IS-707-A, entitled "Data 

15 Service Options for Spread Spectrum Systems", incorporated by reference 
herein, and hereafter referred to as "IS-707." 

IS-707 describes techniques used to provide support for sending Internet 
Protocol (IP) packets through an IS-95 wireless network. Packets are 
encapsulated into a featureless byte stream using a protocol called Point-to- 

20 Point Protocol (PPP). Using PPP, IP datagrams having lengths of up to 1500 
bytes can be transported over a wireless network in segments of arbitrary size. 
The wireless network maintains PPP state information for the duration of the 
PPP session, or as long additional bytes may be sent in the continuous byte 
stream between the PPP end points. 

25 A remote network node such as a personal or laptop computer (PC) 

connected to a packet-data-capable wireless mobile station (MS) may access the 
Internet through a wireless network in accordance with the IS-707 standard. 
Alternatively, the remote network node such as a web browser may be built-in 
to the MS, making the PC optional. An MS may be any of a number of types of 

30 devices including, but not limited to PC card, personal data assistant (PDA), 
external or internal modem, or wireless phone or terminal. The MS sends data 
through the wireless network, where it is processed by a packet data serving 
node (PDSN). The PPP state for a connection between an MS and the wireless 
network is typically maintained within the PDSN. The PDSN is connected to an 

35 IP network such as the Internet, and transports data between the wireless 
network and other entities and agents connected to the IP network. In this way, 
the MS can send and receive data to another entity on the IP network through 
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the wireless data connection. The target entity on the IP network is also called a 
correspondent node. 

The MS must obtain an IP address before sending and receiving IP 
packets over the IP network. In some early implementations, the MS was 
5 assigned an IP address from a pool of addresses belonging exclusively to the 
PDSN. Each PDSN was connected to one or more Radio Access Networks 
(RANs) associated with a limited geographical area. When the MS moved out 
of the area served by the first PDSN, data addressed to the MS through the first 
PDSN could not reach the MS. If the MS moved into an area served by a 
10 second PDSN, the MS would have to be assigned a new IP address from the 
address space of the second PDSN. Any ongoing connection with a 
correspondent node that was based on the old IP address would be abruptly 
terminated. 

In order to prevent connections from being lost when moving from 

15 PDSN to PDSN, MSs use a protocol known as mobile IP. The Internet 
Engineering Task Force (IETF) has standardized mobile IP in request for 
comments (RFC) 2002, entitled "IP Mobility Support," published in October 
1996, and well known in the art. The use of mobile IP in cdma2000 networks 
has been standardized in EIA/TIA/IS-835, entitled "Wireless IP Network 

20 Standard," dated June, 2000, and referred to herein as "IS-835." In mobile IP, 
the PDSN does not provide an IP address from its own pool of addresses. 
Instead, the PDSN acts as a foreign agent (FA) that facilitates assignment of an 
address from a home agent (HA) located somewhere in the IP network. The 
MS communicates through the FA to the FIA, and receives an IP address 

25 assigned from an address pool belonging to the HA. When the MS moves from 
a first PDSN to a second PDSN, the MS communicates through the second 
PDSN and FA in order to re-register its existing IP address with the HA. 

IS-707 and IS-835 describe a dormant mode, in which a wireless link that 
was established for transporting packet data, but which is idle for a certain 

30 period of time, may be reclaimed by the network without terminating the 
associated PPP session. When the flow of packet data resumes, the wireless link 
is re-established without having to repeat PPP configuration and negotiation. 
Preserving the PPP state when the wireless link has been terminated thus 
enables the MS and the wireless network to resume sending packet data more 

35 quickly than if the PPP state had to be re-established. 

The proposed lx standard provides mechanisms to update routing 
between an HA and multiple PDSNs and lx RANs. The proposed HDR 
standards provide mechanisms to update routing between an HA and multiple 
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PDSNs and HDR RANs. Both the HDR and lx standards can effectively update 
packet routing even when an MS changes RANs while in dormant mode, as 
long as the MS does not move to a RAN using a different type of wireless 
interface. For example, if an MS moves from a lx RAN to an HDR RAN while 
5 dormant, routing ambiguities or redundancies can occur, and packets can be 
lost. As these various systems are deployed, there will be a need for 
mechanisms to effectively update routing of packets to an MS moving between 
RANs using different types of wireless interfaces. 

10 SUMMARY 

Embodiments of the present invention are directed to enabling seamless 
handoff of a mobile station (MS) between Radio Access Networks (RANs) that 
use different types of wireless interfaces. The embodiments described herein 

15 enable an MS to handoff between different RANs without causing routing 
ambiguity, and without substantial loss of network data. Upon moving from 
the coverage area of a first RAN using a first wireless interface to the coverage 
area of a second RAN using a second wireless interface, an MS determines 
whether routing ambiguity may result from the change of RAN and, based on 

20 the determination, triggers a re-registration of its network address. A foreign 
agent (FA) within a packet data serving node (PDSN) monitors network 
address re-registrations in order to determine whether multiple RAN-PDSN (R- 
P) connections are being created for the same MS. Based on this determination, 
the PDSN terminates redundant R-P network connections resulting from 

25 movement of the MS between different RANs. 



BRIEF DESCRIPTION OF THE DRAWINGS 

30 The features, objects, and advantages of the present invention will 

become more apparent from the detailed description set forth below when 
taken in conjunction with the drawings in which like reference characters 
identify correspondingly throughout and wherein: 

FIG. 1 is a diagram of a wireless system configuration using only lx 
35 radio access networks (RANs); 

FIG. 2 is an exemplary message flow diagram depicting assignment of 
an IP address to an MS 2 in accordance with the mobile IP standard; 
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FIG. 3 is a diagram of a wireless system configuration using only HDR 
radio access networks (RANs); 

FIG. 4 is a block diagram of a subscriber station apparatus configured in 
accordance with an embodiment of the present invention; 
5 FIG. 5 is a flowchart showing an exemplary process used by an MS when 

handing off between a lx RAN and an HDR RAN capable of performing 
International Mobile Station Identity (IMSI) authentication, in accordance with 
an embodiment of the present invention; 

FIG. 6 is a flowchart showing an exemplary process used by an MS when 
10 handing off between a different RANs, where it is not known whether the HDR 
RANs are capable of performing IMSI authentication, in accordance with an 
embodiment of the present invention; 

FIG. 7 is a flowchart of a handoff process for a destination network 
including a destination PDSN and a destination RAN, and in accordance with 
15 an embodiment of the present invention; and 

FIG. 8 is a block diagram of an exemplary MS configured in accordance 
with an embodiment of the present invention. 

DETAILED DESCRIPTION 

20 

The word "exemplary" is used in this application to mean "serving as an 
example, instance, or illustration." Any embodiment described as an 
"exemplary embodiment" is not to be construed as necessarily preferred or 
advantageous over other embodiments described herein. 

25 FIG. 1 depicts a network configuration in a system using only lx radio 

access networks (RANs) 32, 34, 36. In an exemplary embodiment, a personal or 
laptop computer (PC) 4 is connected to a wireless mobile station (MS) 2 through 
a data connection 12. The data connection 12 between the PC and the MS 2 may 
use a physical cable such as an ethernet, serial, or universal serial bus (USB) 

30 cable. Alternatively, the data connection 12 may be a wireless connection such 
as an infrared or other optical connection or a ratio connection such as 
Bluetooth or IEEE 802.11. As previously discussed, the PC may alternatively be 
incorporated into the MS 2 to enable network access through a single device. In 
the figure, the MS 2 changes its physical location among coverage areas 6, 8, 10 

35 associated with RAN A 32, RAN B 34, and RAN C 36 respectively. RAN A 32 and 
RAN B 34 are connected to PDSNj 14, which in turn is connected to an IP 
Network 18. RAN C 36 is connected to PDSN, 16, which is then connected to the 
IP Network 18. Also accessible through the IP Network 18 are a home agent 
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(HA) 20, an authentication, authorization and accounting (AAA) Server 22, and 
a correspondent node 24. Multiple additional PDSNs, HAs, AAA Servers, and 
correspondent nodes may be connected to the IP Network 18 but are omitted 
for simplicity. 

5 When the MS 2 initially connects to a RAN, for example RAN A 32, the 

MS 2 must obtain an IP address from some entity that is connected with the IP 
network 18. As discussed above, in early implementations the MS 2 was 
assigned an IP address from a pool of addresses allocated to the PDSN 14. 
Because all packets bearing an IP address from that pool of addresses would be 

10 routed to the PDSN 14 by the IP network 18, the PDSN 14 could then route 
those packets to the corresponding MS 2. However, if the MS 2 moved out of 
the coverage of any RAN connected to the PDSN 14, the PDSN 14 would no 
longer be able to forward packets to the MS 2. For example, if the MS 2 moved 
from the coverage area 6 of RAN A 32 to the coverage area 10 of RAN C 36, the 

15 MS 2 would have to obtain a new IP address from the address pool of PDSN 2 
16. Any packets sent to the old address associated with PDSNj 14 would have 
to be discarded, and any ongoing network connections using the old address 
could no longer be used. 

In more recent mobile IP implementations, the MS 2 instead obtains its IP 

20 address from an HA 20 connected to the IP network. After obtaining an 
address from the pool associated with HA 20, mobile IP protocol enables the 
MS 2 to receive packets bearing that IP address through any of multiple RANs, 
32, 34, or 36, or through any of multiple PDSNs 14 or 16. As an alternative to 
dynamic allocation of an IP address from the HA 20, the MS 2 may also have an 

25 IP address within the address pool of HA 20 provisioned in the memory of the 
MS 2 ahead of time, for example upon activation of services. 

FIG. 2 is an exemplary message flow diagram depicting assignment of 
an IP address to an MS 2 in accordance with the mobile IP standard. First, the 
MS 2 originates a wireless link to a RAN connected to PDSN 14 and sends a 

30 first message 202 through a RAN to the PDSN 14. If the MS 2 has an 
international mobile station identity (IMSI), the MS 2 sends the IMSI in the first 
message 202. The first message 202 may be one of several different types, 
depending on the type of wireless interface supported by the RAN or the 
connection state of the wireless link between the MS 2 and the RAN. For 

35 example, the first message 202 may be an origination message if the MS 2 is not 
connected to the RAN, or may be an agent solicitation message if the MS 2 is 
already communicating over a wireless link with the RAN. Though the 
numbering in the example shown indicates PDSNj 14, the first message 202 
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could also be sent through a RAN connected to another PDSN such as PDSN 2 
16. 

In response to the first message 202, the PDSN 14 responds with a 
message 204 containing an agent advertisement and an authentication 
5 challenge. The agent advertisement identifies the address of the foreign agent 
(FA) within the PDSN 14. The authentication challenge is part of a handshake 
that prevents other network entities from accidentally or maliciously using the 
network identity to intercept data packets intended for the MS 2. The MS 2 and 
the authentication, authorization, and accounting (AAA) server 22 are 

10 programmed with shared secret information not available throughout the IP 
network 18. The shared secret information allows the AAA server 22 to verify 
the identity of the MS 2 before the MS 2 is allowed to send requests to the HA 
20. If authentication with the AAA server 22 fails, then the MS 2 cannot request 
an IP address from the HA 20. In an exemplary embodiment, the shared secret 

15 takes the form of a user name and a password. 

Upon receiving the challenge in the message 204 received from the 
PDSN 14, the MS 2 uses its shared secret information in combination with the 
challenge information to form a challenge response that will enable the HA 20 
to verify the identity of the MS 2. For example, the MS 2 uses a one-way 

20 hashing function to combine the shared secret information with the challenge 
information. The MS 2 sends a message 206 back to the PDSN 14 containing the 
challenge information, the challenge response, and a registration request. The 
PDSN 14 then forwards the three pieces of information to the AAA server 22 in 
a message 208. Using the same one-way hashing function, the AAA server 22 

25 can verify the shared secret information used by the MS 2, even though the 
shared secret information itself is never sent through the network. The AAA 
server 22 can be one of several brands or types. In an exemplary embodiment, a 
Remote Authentication Dial In User Service (RADIUS) server is used. 

If the AAA server 22 determines that the challenge response from the MS 

30 2 is valid, the AAA server 22 forwards the registration request 210 to the HA 20. 
The HA 20 has a pool of available IP addresses that it assigns to mobile network 
entities such as the MS 2. Any IP packet sent through the IP network 18 bearing 
a destination address from the HA's 20 pool of addresses are routed by the IP 
network 18 to the HA 20. Based on the contents of the registration request 210, 

35 the HA 20 forms a registration reply 212 containing an IP address to be used as 
a source address in packets sent by the MS 2 to other network entities. The HA 
20 sends the response 212 to the FA in the PDSN 14. The FA records the IP 
address and associates it with and establishes a RAN-PDSN (R-P) session. In an 
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exemplary embodiment, the FA stores the R-P information in a table that is 
indexed according to IP address. To complete the assignment of the IP address 
to the MS 2, the PDSN sends a message 214 to the MS 2 through the RAN. The 
message 214 contains the registration reply from the HA 20 and includes the IP 
5 address allocated to the MS 2. 

After its IP address has been registered, the MS 2 may begin sending IP 
packets throughout the IP network 18. For example, the MS 2 may begin 
communicating with a correspondent node 24, such as a web server. Packets 
sent by the MS 2 bear the destination address of the correspondent node 24 and 

10 the source address assigned to the MS 2. All messages sent by the MS 2 are 
routed through the FA in the PDSN 14. The FA may send an outgoing packet 
straight into the IP network 18 or may encapsulate it in a larger packet 
addressed to the HA 20. If the latter approach is taken, the HA 20 decapsulates 
the packet received from the PDSN 14 and forwards the decapsulated packet to 

15 its destination within the correspondent node 24. 

Responses from the correspondent node 24 will bear the destination 
address assigned to the MS 2 from the address pool belonging to the HA 20. 
All such messages are routed by the IP network 18 to the HA 20. The HA 20 
inspects the destination address of each received IP packet to identify the MS 2 

20 and the associated PDSN 14. Then, the HA 20 encapsulates the packet in a 
larger packet bearing the destination address of the PDSN 14. The 
encapsulated packet is received by the FA in the PDSN 14. The FA 
decapsulates the packet and finds the destination IP address of the 
decapsulated packet in its R-P table. The FA then forwards the packet through 

25 the RAN associated with the corresponding R-P session. To the MS 2, the 
mobile IP process is transparent except for a bit of added delay for all the 
encapsulation, decapsulation, and forwarding. 

In FIG. 1, the MS 2 is shown as being located in the coverage area 6 of 
RAN A 32. In FIG. 1, all the RANs 32, 34, 36 use a lx type of wireless interface. 

30 Networks using a lx wireless interface use IMSIs to identify mobile stations. 
An MS 2 establishing a new wireless link sends its IMSI in the origination 
message. The RAN authenticates the IMSI by exchanging challenge and 
challenge response messages with a home location register (HLR) (not shown). 
The HLR is part of a signaling system 7 (SS7) wireless phone network that is 

35 standardized and well known in the art. Authentication of IMSIs is 
accomplished using techniques similar to the one-way hash function techniques 
described above in association with mobile IP authentication. 
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In an exemplary embodiment as shown in FIG. 1, the MS 2 first 
establishes a connection through a first lx RAN A 32 and registers with the HA 
20 as described above in association with FIG. 2. After mobile IP registration is 
complete, the MS 2 uses an address from the address pool of the HA 20, and 
5 sends packets using a PPP state within the FA in PDSNj 14. In a lx system, 
PDSNj 14 identifies the MS 2 by its IMS! Within the coverage area 6 of RAN A 
32, the MS 2 monitors overhead messages broadcast from base stations in RAN A 
32. Among other types if information, those overhead messages identify the 
packet zone ID (PZID) of RAN A 32. 

10 When the MS 2 leaves the coverage area 6 of RAN A 32 and enters the 

coverage area 8 of RAN B 34, the MS 2 decodes the overhead messages broadcast 
by the base stations in RAN b 34. The RAN B overhead messages contain a 
different PZID than that broadcast by base stations in RAN A . When the MS 2 
detects the change in the PZID, it sends a "fake origination" to RAN B 34. In an 

15 exemplary embodiment, the origination message contains the IMSI of the MS 2, 
a data ready to send (DRS) field, and a PREV_PZID field. Because the 
origination is primarily for route updating purposes, the DRS field is set to 0, 
indicating that the MS 2 does not have packet data to send. If the MS 2 happens 
to have new packet data to be sent to the network, it may originate a regular 

20 call using an origination having a 1 in the DRS field. The PREVJPZID field 
contains the PZID of the previous system to which the MS 2 was connected. 
RAN B 34 receives the origination and forwards the IMSI and the PREV_PZID of 
the MS 2 to its serving PDSN, PDSN X 14. PDSNj 14 determines from the IMSI 
that the MS 2 has an existing PPP state within the PDSNj 14, and determines 

25 from the PREV_PZID value that the MS 2 came from RAN A 32. Because the 
PDSNj is connected to both the original RAN A 32 and the destination RAN B 34, 
the PDSNj can generally just redirect the same PPP state to the destination RAN 
34. If, for some reason, PDSNj 14 cannot redirect the same PPP state to the 
destination RAN 34, PDSNj 14 resets its PPP state and forces the MS 2 to 

30 establish a new PPP session. 

When the MS 2 leaves the coverage area 8 of RAN B 34 and enters the 
coverage area 10 of RAN C 36, the MS 2 decodes the overhead messages 
broadcast by the base stations in RAN C 36. The RAN C 36 overhead messages 
contain a different PZID than broadcast by base stations in RAN B 34. When the 

35 MS 2 detects the change in the PZID, it sends a "fake origination" to RAN C 36 
containing the IMSI of the MS 2, a DRS field having a value of 0, and a 
PREV_PZID field identifying the PZID of the previous RAN, RAN B 34. RAN C 
36 receives the origination and forwards the IMSI and the PREV_PZID of the 
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MS 2 to its serving PDSN, PDSN 2 16. Depending on whether the MS 2 had 
previously been connected to PDSN 2 16, PDSN 2 16 may have a PPP state 
associated with the IMSI of the MS 2. Regardless of the existence of a previous 
PPP state, PDSN 2 16 determines from the PREV_PZID value that the MS 2 came 
5 from a RAN connected to a different PDSN. PDSN 2 16 cannot retrieve a PPP 
state from a different PDSN, and is consequently required to establish a new 
PPP session with the MS 2. If PDSN, 16 had a previous PPP session set up with 
the MS 2, this means that PDSN, 16 must discard that PPP session. 

After a new PPP session is established between the MS 2 and PDSN 2 16, 

10 PDSN 2 16 sends an agent advertisement message to the MS 2 identifying the 
address of the FA within PDSN, 16. Because the address of each FA is different, 
the FA address of PDSN, 16 will be different than the FA address of PDSN X 14. 
When the MS 2 receives an agent advertisement having a different address, the 
MS determines that it must re-register its IP address with the HA 20. The MS 2 

15 re-registers its IP address with the HA 20, for example according to the protocol 
described in association with FIG. 2. Using mobile IP authentication as 
described above, the HA 20 recognizes that the MS 2 has moved and is 
requesting the same IP address. If possible, the HA 20 allocates the same IP 
address to the MS 2 and redirects messages destined for that address to PDSN, 

20 16. Generally, the HA 20 does not send notification of the redirection to the 
original PDSN, PDSN 1 14. 

FIG. 3 depicts a network configuration in a system using only HDR 
RANs 42, 44, 46. The MS 2 is initially located in the coverage area 6 of RAN A 42. 
In FIG. 3, all the RANs 42, 44, 46 use an HDR type of wireless interface. 

25 Networks using an HDR wireless interface use Unicast Access Terminal 
Identifiers (UATIs) to identify mobile stations. 

An HDR RAN generally does not obtain an IMSI from an MS 2, but 
assigns an IMSI to each MS 2 primarily to allow identification of R-P sessions 
with a PDSN. By providing some IMSI support, an HDR network can use the 

30 same kind of PDSN used by lx systems. In general, a strictly HDR network 
does not perform any IMSI authentication, and is not connected to an SS7 
wireless phone network. In an exemplary embodiment, a database of UATIs, 
IMSIs, and other information is distributed among HDR RANs in a wireless 
network. 

35 The MS 2 connects to an HDR system through a first HDR RAN, for 

example RAN A 42, and obtains a UATI from RAN A 42. RAN A 42 then assigns a 
temporary IMSI to the MS 2 in order to enable packet data to be routed by the 
FA in PDSNj 14. Alternatively, if RAN A 42 is capable of authenticating the 
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IMSI, RAN A 42 assigns the actual IMSI to the MS 2 in establishing the R-P link 
with PDSNj 14. If RAN A 42 is capable of authenticating the IMSI, it may do so 
using an Authentication Center on an SS7 network or using the AAA server 22. 
The MS 2 then registers with the HA 20 as described above in association with 
5 FIG. 2. After mobile IP registration is complete, the MS 2 uses the IP address 
assigned to it by the HA 20, and sends packets using a PPP state within the FA 
in PDSNj 14. Within the coverage area 6 of RAN A 42, the MS 2 monitors 
overhead messages broadcast from base stations in RAN A 42. In an exemplary 
embodiment, the overhead messages include information that enables the MS 2 

10 to determine when it is located within the coverage area 6 associated with base 
stations of RAN A 42. The overhead messages that allow the MS 2 to identify the 
RAN associated with a coverage area are referred to as a subnet mask. When 
the MS 2 leaves one coverage area and enters another, the subnet mask received 
on the overhead channels will change accordingly. 

15 When the MS 2 leaves the coverage area 6 of RAN A 42 and enters the 

coverage area 8 of RAN B 44, the MS 2 decodes the overhead messages broadcast 
by the base stations in RAN b 44. When the MS 2 detects the change in the 
subnet mask, it sends a UATI Update message to RAN B 44. The UATI Update 
message contains the UATI assigned to the MS 2 by RAN A 42. RAN B 44 

20 determines that the UATI was assigned by some other RAN, and queries other 
HDR RANs connected to the same network for the UATI. As described above, 
a database of UATIs, PPP state information, IMSIs, and other information is 
distributed among HDR RANs in a wireless network. Based on the previously 
assigned UATI, RAN B 42 obtains the table information associated with the MS 

25 2. Because both RAN A 42 and RAN B 44 are connected to PDSNj 14, RAN B 44 
determines the temporary IMSI associated with the MS's 2 UATI and notifies 
PDSN X 14 that the MS 2 associated with that IMSI has moved to RAN B 44. 

When the MS 2 leaves the coverage area 8 of RAN B 44 and enters the 
coverage area 10 of RAN C 46, the MS 2 decodes the overhead messages 

30 broadcast by the base stations in RAN C 46. The RAN C 46 overhead messages 
contain a different subnet mask than broadcast by base stations in RAN B 44. 
When the MS 2 detects the change in the subnet mask, it sends a UATI Update 
message to RAN C 46 containing the MS's 2 previously assigned UATI. RAN C 46 
receives the UATI Update message and queries other RANs connected to 

35 PDSN 2 16 to determine whether the MS 2 received its UATI assignment from a 
nearby RAN. Because the MS 2 received its UATI assignment in RAN B 44, 
which is connected to PDSN a 14, RAN C 46 will be unable to redirect the PPP 
state to itself. RAN C 46 therefore assigns a new UATI to the MS 2 and forces the 
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MS 2 to establish a new PPP session. The MS 2 will consequently lose state 
information associated with its previous PDSN 1 14 PPP session. 

After a new PPP session is established between the MS 2 and PDSN 2 16, 
PDSN 2 16 sends an agent advertisement message to the MS 2 identifying the 
5 address of the FA within PDSN 2 16. Because the address of each FA is different, 
the FA address of PDSN 2 16 will be different than the FA address of PDSN, 14. 
When the MS 2 receives an agent advertisement having a different address, the 
MS determines that it must re-register its IP address with the HA 20. The MS 2 
re-registers its IP address with the HA 20, for example according to the protocol 

10 described in association with FIG. 2. Using mobile IP authentication as 
described above, the HA 20 recognizes that the MS 2 has moved and is 
requesting the same IP address. If possible, the HA 20 allocates the same IP 
address to the MS 2 and then redirects messages destined for that address to 
PDSN 2 16. Generally, the HA 20 does not send notification of the redirection to 

15 the original PDSN, PDSN, 14. 

FIG. 4 depicts a network configuration in a system using a mixture of 
HDR RANs 52, 56 and lx RANs 54. The MS 2 is initially located in the coverage 
area 6 of RAN A 52. An MS 2 designed to operate in a mixed HDR and lx 

20 system has attributes of both systems. For example, it has an IMSI stored in 
memory, but is also programmed to connect to an HDR network using a UATI. 

If HDR RANs 52, 56 are capable of performing authentication of IMSIs, 
then R-P links with PDSNs 14 and 16 can be established using the actual IMSI of 
the MS 2. IMSI authentication may be accomplished by an HDR RAN using an 

25 Authentication Center on an SS7 network or using the AAA server 22. In an 
exemplary embodiment, the MS 2 sends its IMSI to an HDR RAN at the 
beginning of HDR session negotiations. Each HDR RAN 52, 56 can then use the 
true IMSI of the MS 2 to establish its R-P links with PDSNs 14 and 16. Because 
the same IMSI is used for both the lx RAN 54 and the HDR RANs 52, 56, the 

30 PDSN can easily resolve any routing ambiguity and avoid mis-routing any 
packets addressed to the MS 2. Furthermore, if the previous lx RAN and the 
destination HDR RAN share a single PDSN, for example in a configuration 
similar to that of RAN A 52, RAN B 54, and PDSN, 14, the PDSN can re-route its 
R-P connection to the destination RAN and re-use the existing PPP state. 

35 However, if HDR RANs 52 and 56 are not capable of authenticating 

IMSIs, they will create temporary IMSIs for use in R-P links with PDSNs 14 and 
16. A subsequent handoff from a lx RAN to an HDR RAN, for example from 
RAN B 54 to RAN A 52, can cause routing problems in a shared PDSN such as 
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PDSNj 14. In an exemplary embodiment, routing problems caused by the 
creation of multiple R-P sessions having the same IP address but different IMSIs 
are addressed with minor modifications to PDSN operation. 

In an exemplary embodiment, the MS 2 connects to an HDR system 
5 RAN A 52, and obtains a UATI from RAN A 52. RAN A 52 then assigns a 
temporary IMSI to the MS 2 in order to enable packet data to be routed by the 
FA in PDSNj 14. The MS 2 then registers with the HA 20 as described above in 
association with FIG. 2. After mobile IP registration is complete, the MS 2 uses 
the IP address assigned to it by the HA 20, and sends packets using a PPP state 

10 within the FA in PDSN X 14. Within the coverage area 6 of RAN A 52, the MS 2 
monitors overhead messages broadcast from base stations in RAN A 52. 

When the MS 2 leaves the coverage area 6 of RAN A 52 and enters the 
coverage area 8 of RAN B 54, the MS 2 decodes the overhead messages broadcast 
by the base stations in RAN B 54. As discussed above, a lx RAN like RAN B 54 

15 broadcasts a PZID on its overhead channels. So, the MS 2 receives a subnet 
mask from RAN A 52 and a PZID from RAN B 54. From the different overhead 
messages received from RAN B 54, the MS 2 determines that it has moved into 
coverage of a network having a different type of wireless interface. As 
explained below, the MS 2 and PDSNj 14 must take special precautions to 

20 prevent packets destined for the MS 2 from being lost due to routing ambiguity. 

In response to the change of network, the MS 2 sends to RAN B 54 a "fake 
origination" containing the actual IMSI of the MS 2. As a result, RAN B 54 
establishes a new R-P connection with PDSNj 14 based on the actual IMSI of the 
MS 2. If PDSN, 14 has not previously established a PPP state with the MS 2 

25 based on the actual IMSI, then PDSNj 14 negotiates a new PPP state with the 
MS 2. After a new PPP session is established between the MS 2 and PDSN X 14, 
PDSN X 14 sends an agent advertisement message to the MS 2 identifying the 
address of the FA within PDSNj 14. Because the PDSN has not changed, the FA 
address sent in the agent advertisement message will be the same as that 

30 received from RAN A 52. As a result, the MS 2 may not re-register its IP address 
with the HA 20. Because the MS 2 obtained its IP address from HA 20 through 
RAN A 52, RAN A 52 assigned a temporary IMSI to the MS 2. The IP address 
being used by the MS 2 is linked to the temporary IMSI in the FA within PDSNj 
14. All network packets arriving at the FA in PDSN! 14 bearing that IP address 

35 will be routed to RAN A 52 unless the MS 2 re-registers its IP address with the 
HA 20. 

In an exemplary embodiment, the MS 2 performs mobile IP re- 
registration whenever it moves from the coverage area of an HDR RAN 52, 56 
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into the coverage area of a lx RAN 54. For example, if the MS 2 moves from the 
coverage area 6 of RAN A 52 to the coverage area 8 of RAN B 54, the MS 2 re- 
registers its address with the HA 20 even if the FA address received in the agent 
advertisement message is the same as the one used immediately prior. 
5 Unfortunately, re-registering with the HA 20 does not entirely solve the 

routing ambiguity. When the MS 2 first obtains its IP address from the HA 20 
through RAN A 52, the foreign agent in PDSN : 14 associates an R-P session with 
the combination of temporary IMSI and IP address used. After the MS 2 moves 
into the coverage area of RAN B 54, the MS 2 re-registers with the HA 20 and is 

10 generally allocated the same IP address. Unfortunately, the re-registration uses 
the actual IMSI of the MS 2 instead of the temporary IMSI initially assigned by 
RAN A 52. Consequently, PDSNj 14 will end up having the same IP address 
assigned to two different R-P sessions, each corresponding to a different IMSI. 
When a packet arrives from the IP network 18 bearing that IP address, PDSNj 

15 14 will be unable to unambiguously route the packet to a RAN. 

In an exemplary embodiment, the PDSNs in a mixed network are 
modified to prevent such ambiguity. Any time the FA assigns an IP address to 
an IMSI, the FA purges its tables of any other entries bearing the same IP 
address, regardless of the value of the IMSI. Only one R-P session per IP 

20 address is allowed within an FA of a PDSN. 

In addition to the case where an MS 2 moves from an HDR system to a 
lx system, special precautions must be taken to avoid routing ambiguity when 
the MS 2 moves from a lx system to an HDR system. The problems may be 
particularly acute when an MS 2 establishes a connection through an HDR 

25 RAN, such as RAN C 56, then moves to a lx RAN such as RAN B 54 , served by a 
different PDSN, re-registers its IP address with the HA 20 while in RAN B 54, 
and then returns to RAN C 56. In the currently proposed HDR standards, there 
is no way for an MS 2 to notify the RAN C 56 that it has just come from a system 
that uses a different wireless interface or that it has re-registered its IP address 

30 in the other system. This is not a problem when moving from a lx RAN to a lx 
RAN, because the PREV_PZID in the fake origination allows the PDSN to 
determine that the MS 2 re-registered through a different PDSN. This is also 
not a problem when moving from an HDR RAN to an HDR RAN, because the 
UATI in the UATI Request allows the destination PDSN to determine whether 

35 the MS 2 re-registered through a different PDSN. 

When the MS 2 reenters the coverage area 10 of HDR RAN C 56 from lx 
RAN B 54, the MS 2 sends a UATI Request containing the UATI used by the MS 
2 when previously in the coverage area 10 of HDR RAN C 56. The MS 2 has no 
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way, using the currently proposed protocols, to notify HDR RAN C 56 of its re- 
registration in the intervening lx system. Consequently, RAN C 56 will resume 
network communications using the existing PPP state in PDSN 2 16 associated 
with the UATI used previously by the MS 2. 
5 In an exemplary embodiment, the MS 2 always resets its UATI upon 

moving from a lx RAN to an HDR RAN. When the reset UATI is sent in the 
UATI Request, the HDR RAN will assign a new UATI to the MS 2 and thus 
force a mobile IP re-registration. The mobile IP re-registration will generally 
result in the MS 2 being assigned the same IP address it was using previously. 

10 Upon completion of the mobile IP re-registration, the HA 20 will properly 
direct network packets to the HDR RAN, and to the MS 2. In an alternate 
embodiment, the MS 2 accomplishes substantially the same thing by simply 
forcing a PPP reset whenever the MS 2 moves from a lx RAN to an HDR RAN. 
In another embodiment, the HDR standard is altered to allow the MS 2 

15 to initiate a LocationResponse message to the HDR RAN. In the existing HDR 
specification, the LocationResponse message may contain the system identifier 
(SID), network identifier (NID), and PZID of the previous system in which the 
MS 2 re-registered its IP address. Armed with this information, the HDR RAN 
could query its PDSN to possibly shift the R-P session to the HDR RAN. Or, if 

20 the PZID belongs to a lx RAN associated with a different PDSN, the PDSN can 
reset the PPP session and thus trigger an IP address re-registration. 

In another embodiment, the MS 2 sends a mobile IP AgentSolicitation 
message to the FA in the destination PDSN. Based on the address of the FA 
gleaned from the response, the MS 2 can re-register its IP address with the HA 

25 20 without expending the bandwidth necessary to establish a new PPP session. 

FIG. 5 is a flowchart showing an exemplary process used by the MS 2 
when handing off between a lx RAN and an HDR RAN capable of performing 
IMSI authentication. Upon detecting a change of RAN type, the MS 2 sends its 
IMSI to the destination RAN at step 502. If the destination RAN is a lx RAN, 

30 the IMSI may be sent in the origination message for a "fake origination." If the 
destination RAN is an HDR RAN, the IMSI may be sent in a configuration 
message while the new HDR session is being negotiated. 

If the PDSN connected to the destination RAN does not have an R-P 
session associated with the IMSI of the MS 2, the PDSN will establish a new PPP 

35 session with the MS 2. At step 504, the MS 2 determines whether a new PPP 
session has been established with the PDSN. The establishment of a new PPP 
session by the PDSN could mean that the PDSN has no existing PPP state 
associated with the IMSI of the MS 2. Alternatively, the establishment of a new 
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PPP session by the PDSN could mean that the PDSN cannot transfer an existing 
PPP state from an R-P session of a previous RAN to the destination RAN. In 
either case, the PDSN will generally send an agent advertisement message to 
the MS 2 indicating the address of the FA within the PDSN. If the previous 
5 RAN providing service to the MS 2 was connected to the same PDSN, then it 
might not be necessary to re-register mobile IP with the HA 20. The HA 20 
would forward packets to the correct PDSN. However, if the previous RAN 
providing service to the MS 2 was connected to a different PDSN, then the MS 2 
should re-register mobile IP in order to notify the HA 20 of the new PDSN 

10 address. Because the MS 2 cannot determine whether the new PPP state was 
necessitated by a change of PDSN, the MS re-registers its mobile IP address 
with the HA 20 at step 506. 

If, at step 504, the MS 2 determines that no new PPP session has been 
established with the PDSN, then the MS 2 determines, at step 508, whether a 

15 mobile IP re-registration occurred in the previous RAN type. As discussed 
above, protocols used with the different wireless interfaces are designed to 
manage movement of the MS 2 among different RANs of the same type. Thus, 
when the MS 2 moves among RANs of the same type, no routing ambiguity 
results. When moving among lx RANs, the MS 2 sends information about the 

20 previous RAN such as the PZID to allow the destination RAN to determine 
whether a new PPP session should be established. When the MS 2 is moving 
among HDR RANs, the destination RAN determines whether a new PPP 
session is needed by comparing the UATI received from the MS 2 in a UATI 
update message. 

25 However, when the MS 2 returns to a RAN having a different type of 

wireless interface, the messages it sends to the destination RAN do not identify 
a previous RAN of a different type. If the destination RAN is an HDR RAN, the 
MS 2 cannot send a previous PZID value in a UATI update message. Likewise, 
the MS 2 cannot send a UATI in a lx origination. If the previous RAN and the 

30 destination RAN are connected to different PDSNs, and the MS 2 re-registered 
its mobile IP address with the HA 20 in the previous system, the HA 20 will still 
send subsequent packets addressed to the MS 2 to the previous RAN's PDSN. 
In order to prevent such routing ambiguity, if the MS 2 performed a mobile IP 
re-registration in the previous RAN type, it re-registers its mobile IP address at 

35 step 506. 

FIG. 6 is a flowchart showing an exemplary process used by the MS 2 
when handing off between different RANs, when it is not known whether the 
HDR RANs are capable of performing IMSI authentication. Upon detecting a 
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change of RAN, the MS 2 sends its IMSI to the destination RAN at step 602. 
The MS 2 then determines, in steps 604, 606, 608 which of four possible handoff 
types is required: (1) HDR-to-HDR; (2) lx-to-lx; (3) HDR-to-lx; or (4) lx-to- 
HDR. The MS 2 processes each different handoff type differently. 
5 At step 604, the MS 2 determines the type of the previous RAN. If the 

previous RAN was an HDR RAN, the MS 2 then determines, at step 606, the 
type of the destination RAN. If the destination RAN is also HDR, then the MS 2 
sends a UATI Request to the destination RAN at step 608. Then, the MS 2 
determines, at step 618, whether the destination PDSN established a new PPP 

10 session. If the destination PDSN did not establish a new PPP session, the MS 2 
continues normal operation and can send and receive packet data through the 
destination RAN. Otherwise, the MS 2 re-registers its mobile IP address with 
the HA 20 at step 624. 

If, at step 604, the MS 2 determines that the previous RAN was a lx 

15 RAN, the MS 2 then determines, at step 614, the type of the destination RAN. If 
the destination RAN is also lx, then the MS 2 sends an origination message to 
the destination RAN at step 616. As discussed above, this origination message 
can be a "fake origination" containing a DRS field value of 0. The origination 
message contains the MS's 2 IMSI and any system identification values 

20 associated with the destination RAN that are different from those for the 
previous RAN, such as the PZID. Based on the information in the origination 
message, the PDSN connected to the destination RAN may establish a new PPP 
session. At step 620, the MS 2 determines whether the destination PDSN 
established a new PPP session. If the destination PDSN did not establish a new 

25 PPP session, the MS 2 continues normal operation and can send and receive 
packet data through the destination RAN. Otherwise, the MS 2 receives an 
agent advertisement at step 622 and compares the FA address to the FA address 
previously used to register a mobile IP address with the HA 20. If the previous 
FA address is different from the address of the destination FA, the MS 2 re- 

30 registers its mobile IP address at step 624. Otherwise, the MS 2 continues 
normal operation and can send and receive packet data through the destination 
RAN. 

If, at step 606, the MS 2 determines that the destination RAN is a lx 
RAN, then the MS 2 sends an origination message at step 610. This origination 
35 message can be a "fake origination" containing a DRS field value of 0. In an 
exemplary embodiment, when handing off to an HDR RAN, the MS 2 saves the 
system identification values of the previous lx RAN. The origination message 
contains the MS's 2 IMSI and may contain previous system identification values 
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such as PZID, SID, or NID. After sending the origination at step 610, the MS 2 
continues to step 618 described above. 

If, at step 614, the MS 2 determines that the destination RAN is an HDR 
RAN, then the MS 2 sends a Location Update message at step 612. In an 
5 exemplary embodiment, the Location Update message contains the PZID, SID, 
and NID of the previous lx RAN. In an exemplary embodiment, the Location 
Update message contains a LocationValue field as defined in the HDR 
specification. The destination HDR RAN may use the information in the 
Location Update message to determine whether the MS 2 is handing off from a 

10 previous RAN connected to a different PDSN. If the previous RAN and the 
destination RAN share a PDSN, then the PDSN may be able to move the R-P 
state associated with the MS 2 to the destination RAN without requiring a 
mobile IP re-registration or establishment of a new PPP session. After sending 
the Location Update message, the MS 2 continues to step 618 described above. 

15 FIG. 7 (FIGS. 7a and 7b) is a flowchart of a handoff process for a 

destination network including the destination PDSN and the destination RAN. 
At step 704, the destination RAN receives identification information from the 
incoming MS 2. The identification information may include an IMSI, a UATI, or 
system identification information associated with the previous RAN such as 

20 PZID, SID, or NID. As discussed above, the types of identification information 
received from an incoming MS 2 may vary based on the wireless interfaces used 
by the previous and destination RANs. 

At step 706, the destination network searches for an existing PPP session 
associated with the incoming MS 2. In an HDR network, this can include 

25 searching for IMSIs, UATIs, or other information distributed among multiple 
HDR RANs. In a lx network, this can include searching for the IMSI of the MS 
2 in a database within the destination PDSN. In either type of network, the 
search may include authenticating the IMSI received from the MS 2. If the 
destination network supports IMSI authentication, and the MS 2 cannot be 

30 successfully authenticated, the network will either deny packet services to the 
MS or, in the case of an HDR RAN, will assign a temporary IMSI to identify the 
R-P session in the DESTINATION PDSN. Ultimately, at step 708, the 
DESTINATION PDSN determines whether or not it has an existing R-P session 
associated with the incoming MS 2. 

35 If a session can be found, then at step 710 the destination network 

determines whether an identified previous RAN is connected to the destination 
PDSN. If so, then the destination PDSN redirects its R-P session to the 
destination RAN at step 712, and packet data service to the MS 2 can continue 
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without mobile IP re-registration or establishment of a new PPP session. If a 
session cannot be found, then at step 714 the destination PDSN establishes a 
new PPP session with the incoming MS 2. After the new PPP session is 
established, the destination PDSN sends, at step 716, an agent advertisement 
5 containing the address of the FA within the destination PDSN to the incoming 
MS 2. At step 718, if the agent advertisement does not cause the incoming MS 2 
to re-register its IP address with the HA 20, then packet data service to the MS 2 
can continue. 

If, at step 718, the incoming MS 2 re-registers its IP address, then at step 

10 720, the destination PDSN monitors the IP address assigned to the incoming MS 
2 through its FA. If the assigned IP address matches the IP address associated 
with any other R-P sessions in the PDSN, then at step 722 the PDSN terminates 
the other R-P sessions. The PDSN terminates such other R-P sessions even if 
they have different IMSIs to prevent any routing ambiguity. After step 722, or 

15 if, at step 718, the incoming MS 2 does not re-register its IP address, then packet 
data service to the MS 2 can continue. 

FIG. 8 shows an exemplary MS 2 apparatus. As discussed above, the MS 
2 may have a data connection 12 to an external terminal or device such as a 
personal or laptop computer (PC) 4. In such a configuration, the MS 2 includes 

20 a local interface 812 to provide necessary conversions of data connection signals 
and digital data. The local interface 812 can be any of a variety of cabled 
interface types such an ethernet, serial, or universal serial bus (USB). 
Alternatively, the local interface 812 may provide a wireless connection such as 
an infrared or other optical connection or a radio connection such as Bluetooth 

25 or IEEE 802.11. 

Instead of providing a connection to an external PC 4, the MS 2 may 
provide direct access to the IP network 18. For example, the MS 2 may include 
a web browser application using such protocols as the Wireless Application 
Protocol (WAP). In such an incorporated application, the local interface 812 

30 may take the form of a user interface including keypads, LCD displays, or 
touch-sensitive displays such as pen input interfaces like those commonly used 
on handheld personal digital assistant devices (PDAs), or any other input 
interface appropriate for wireless packet data user applications. 

In an exemplary embodiment, the local interface 812 provides 

35 application data to a control processor 804. The control processor 804 may be a 
general-purpose microprocessor, digital signal processor (DSP), programmable 
logic device, application specific integrated circuit (ASIC), or any other device 
capable of performing the functions described herein. The handset user input 
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interface and handset display may include a keypad, a liquid crystal display 
(LCD) pen input interface such as those commonly used on handheld personal 
digital assistant devices (PDAs), or any other input interface appropriate for 
wireless packet data user applications. 
5 In addition, the control processor 804 is configured to perform the MS 2 

processing described in conjunction with FIGS. 1-7, such as requesting IP 
resources, managing PPP sessions, and other network protocol processes 
associated with the various wireless interfaces. The control processor 804 may 
be a single processor, or may include multiple separate processors such as a 

10 microcontroller for managing user interface functions through the local 
interface 812 and a DSP for managing wireless interface protocols. 

The MS 2 includes a memory 802 for storing the various types of data 
and information needed during operation of the control processor 804. The 
memory 802 may be a single device or may include multiple devices such as 

15 non-volatile memory including flash memory, static or dynamic random access 
memory (RAM), or erasable or non-erasable read-only memory (ROM). The 
entire memory 802 or portions thereof may be incorporated into a single device 
with the entire control processor 804 or portions thereof. The memory 802 may 
contain such information as the executable code for the control processor 804, 

20 the IMSI, the shared secret information used to register a mobile IP address, the 
address of the HA 20, and the mobile IP address. Additionally, the memory 802 
is configured to store temporary copies of packet data transmitted to and 
received from the wireless network, and all the state variables necessary for 
providing packet data services. 

25 In an exemplary embodiment, data to be sent to the wireless network is 

encoded, modulated, and interleaved in a modulator (MOD) 806, and amplified 
and upconverted in a transmitter (TMTR) 808 before being transmitted through 
a diplexer (DIP) 810 and an antenna 814. Data received from the wireless 
network through the antenna 814 is gain-controlled and downconverted in a 

30 receiver (RCVR) 816, deinterleaved, demodulated, and decoded in a 
demodulator (DEMOD) 818 before being processed by the control processor 
804. The modulator (MOD) 806, transmitter (TMTR) 808, receiver (RCVR) 816, 
and demodulator (DEMOD) 818 are capable of operating using multiple types 
of wireless interfaces, for example lx and HDR. If necessary, the MS 2 includes 

35 multiple modulators, transmitters, receivers, or demodulators as necessary for 
compatibility with the multiple types of wireless interfaces, including lx, HDR, 
W-CDMA, and EDGE. 
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The previous description of the preferred embodiments is provided to 
enable any person skilled in the art to make or use the present invention. The 
various modifications to these embodiments will be readily apparent to those 
skilled in the art, and the generic principles defined herein may be applied to 
5 other embodiments without the use of the inventive faculty. Thus, the present 
invention is not intended to be limited to the embodiments shown herein but is 
to be accorded the widest scope consistent with the principles and novel 
features disclosed herein. 



WHAT IS CLAIMED IS: 
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CLAIMS 

1. A method of performing a handoff of a mobile station between a first 
2 radio access network of a first type and a second radio access network of a 

second type, comprising: 
4 determining, at the mobile station, whether changing from 

communicating over the first radio access network to communicating over the 
6 second radio access network will cause routing ambiguity for data sent to and 

from the mobile station; and 
8 triggering, at the mobile station, a re-registration of a network address of 

the mobile station if changing from communicating over the first radio access 
10 network to communicating over the second radio access network will cause 

routing ambiguity for data sent to and from the mobile station. 

2. In a packet data serving node of a communications network, a 
2 method of compensating for a handoff of a mobile station between a radio 

access network of a first type and a radio access network of a second type, 
4 comprising: 

determining, at the packet data serving node, whether multiple radio- 
6 access-network-to-packet-data-serving-node (R-P) connections are being 

created for the same mobile station; and 
8 terminating, at the packet data serving node, redundant R-P connections 

resulting from movement of the mobile station between a radio access network 
10 of a first type and a radio access network of a second type. 

3. The method of claim 2, further comprising monitoring, at the 

2 packet data serving node, network address re-registrations of mobile stations. 

4. A mobile station, comprising: 
2 a control processor; and 

a memory coupled to the control processor and containing instructions 
4 executable by the processor to determine whether handing off from a radio 

access network of a first type to a radio access network of a second type will 
6 cause routing ambiguity for data sent to and from the mobile station, and 

triggering a re-registration of a network address of the mobile station based on 
8 the determination. 

5. A mobile station, comprising: 
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2 means for determining whether handing off communications from a 

radio access network of a first type to a radio access network of a second type 

4 will cause routing ambiguity for data sent to and from the mobile station; and 
2means for triggering a re-registration of a network address of the mobile 

6 station based on the determination. 
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